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Abstract 

As  modern  systems  continue  to  increase  in  size  and  complex¬ 
ity,  they  pose  increasingly  significant  safety  and  risk  manage¬ 
ment  challenges.  A  model-based  safety  approach  is  an  effi¬ 
cient  way  of  coping  with  the  increasing  system  complexity. 
It  helps  better  manage  the  complexity  by  utilizing  reasoning 
tools  that  require  abstract  models  to  detect  failures  as  early 
as  possible  during  the  design  process.  This  paper  develops  a 
methodology  for  the  verification  of  safety  requirements  for 
design  of  complex  engineered  systems.  The  proposed  ap¬ 
proach  combines  a  SysML  modeling  approach  to  document 
and  structure  safety  requirements,  and  an  assume- guarantee 
technique  for  the  formal  verification  purpose.  The  assume- 
guarantee  approach,  which  is  based  on  a  compositional  and 
hierarchical  reasoning  combined  with  a  learning  algorithm, 
is  able  to  simplify  complex  design  verification  problems.  The 
objective  of  the  proposed  methodology  is  to  integrate  safety 
into  early  design  stages  and  help  the  system  designers  to  con¬ 
sider  safety  implications  during  conceptual  design  synthesis, 
reducing  design  iterations  and  cost.  The  proposed  approach 
is  validated  on  the  quad-redundant  Electro-Mechanical  Actu¬ 
ator  (EM A)  of  a  Flight  Control  Surface  (FCS)  of  an  aircraft. 

1.  Introduction 

In  recent  years,  technological  advancements  and  a  growing 
demand  for  highly  reliable  complex  engineered  systems,  e.g., 
space  systems,  aircrafts,  and  nuclear  power  plants  have  made 
the  safety  assessment  of  these  systems  even  more  important. 
Moreover,  the  growing  complexity  of  such  systems  has  made 
it  more  challenging  to  achieve  design  solutions  that  satisfy 
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safety  and  reliability  requirements  (Wiese  &  John,  2003;  Zio, 
2009;  N.  Leveson,  201 1).  Hollnagel  et  al.  (Hollnagel,  Woods, 

&  Leveson,  2007)  recognize  the  fact  that  safety  violation  in 
complex  systems  is  not  necessarily  a  consequence  of  com¬ 
ponents’  malfunction  or  a  faulty  design.  Rather  it  could  be 
a  result  of  a  network  of  ongoing  interactions  between  all  the 
components  and  subsystems  that  introduce  undesired  behav¬ 
ior.  For  this  reason,  Baroth  et  al.  (Baroth  et  al.,  2001)  recom¬ 
mends  the  Prognostic  and  Health  Management  System  (PHMS) 
as  a  new  technology  to  replaces  the  traditional  build-in  test 
(BIT)  with  intelligent  prognostics  tools  to  predict  the  occur¬ 
rence  of  unexpected  faults.  However,  given  the  local  safety 
properties  of  each  component,  it  is  not  a  trivial  matter  to  infer 
the  safety  and  reliability  of  the  whole  system  (N.  G.  Leve¬ 
son,  2009).  Well- specified  verification  formalism  and  rea¬ 
soning  tools  are  needed  to  study  the  emerging  behavior  and 
to  perform  exhaustive  verification  of  safety  properties.  A  se¬ 
ries  of  safety  standards  emerged  in  recent  years  that  recognize 
this  issue  and  strongly  recommended  the  use  of  formal  veri¬ 
fication  methods  to  control  the  complexity  of  safety-critical 
systems,  i.e.,  the  international  standard  on  safety  related  sys¬ 
tems  (IEC,  1998)  and  the  SAE  &  EUROCAE  standards  in  the 
avionic  industry  (ARP4761,  1996;  ARP4754,  1996).  How¬ 
ever,  these  standards  do  not  specify  how  to  implement  formal 
approaches  throughout  the  design  process. 

Strategies  for  engineered  system  design  emerge  from  a  pro¬ 
cess  of  requirement  decomposition  and  transforming  require¬ 
ment  models  into  the  conceptual  models  (Blanchard,  2012; 
Buede,  2011).  Requirement  models,  noted  R ,  capture  the  de¬ 
sign  problem  being  solved  and  conceptual  models,  noted  S , 
represent  the  specific  solution  for  the  design  problem.  There¬ 
fore,  the  first  step  in  specifying  and  formulating  a  complex 
system  is  to  capture  its  requirements  R  and  decompose  it  into 
the  requirements  of  its  sub-systems  and  components,  noted 
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R  =  {i?i,  i?2, Rn}-  The  second  step  is  to  create  a  re¬ 
lationship  between  design  requirements  and  the  system  that 
consists  of  heterogenous  sub-systems,  i.e.,  electrical,  mechan¬ 
ical,  and  software  ...,  noted  S  =  {Si,  S2, Sm}.  However, 
this  relationship  between  the  set  of  design  requirements  and 
the  set  of  sub-systems  and  components  is  a  non  bijective  re¬ 
lationship.  A  commonly  used  formalism  to  address  this  prob¬ 
lem  is  to  focus  on  discrete  event  system  dynamics.  This  for¬ 
mulation  is  extended  (Hirtz,  Stone,  McAdams,  Szykman,  & 
Wood,  2002;  Nagel,  Stone,  Hutcheson,  McAdams,  &  Don- 
ndelinger,  2008;  Kurtoglu  &  Campbell,  2009)  by  considering 
other  system  features  such  as  structures  and  functions,  so  that 
the  predicate  (Si  A  S2  A  ...  A  Sm  =>  Design’s  Objective)  is 
preserved  and  satisfied  throughout  the  design  process.  So  the 
formulation  can  be  summarized  as  below: 


Si  =4>  {Rk}ke[i..n\  satisfies  a  sub-set  of 
requirements. 

{Sk}ke[i..m]  =>  Ri  Ri  satisfied  by  sub-set  of 

sub- systems  or  components. 

The  process  of  identifying  and  proving  the  correctness  of  these 
relationships  with  regards  to  design  safety  requirements  is 
the  objective  of  this  paper.  The  remainder  of  this  paper  is 
structured  as  follows:  section  2  discusses  the  system  oriented 
approaches  and  their  ability  in  modeling  multi-domain  com¬ 
plex  engineered  system  and  being  exploitable  for  safety  anal¬ 
ysis.  Furthermore,  formal  verification  methods  and  the  def¬ 
inition  of  compositional  reasoning  and  its  commonly  used 
terminologies  and  operators  are  introduced  as  a  complemen¬ 
tary  technique  to  design  requirement  analysis.  In  section  3 
an  overview  of  the  step-by-step  implementation  of  the  com¬ 
positional  reasoning  algorithm  on  the  components  of  the  de¬ 
sign  architectures  is  explained.  Further,  section  3  outlines 
the  application  of  the  proposed  methodology  in  the  analysis 
and  verification  of  the  safety  properties  of  the  quad-redundant 
Electro  Mechanical  Actuator  (EM A)  system  design.  The  pa¬ 
per  ends  with  conclusion. 

2.  Related  Work 

Different  standards,  e.g.,  (IEEE1220,  2005;  ISO-IEC15288, 
2002)  have  defined  system  design  as  a  multidisciplinary  col¬ 
laborative  process  that  defines,  develops,  and  verifies  a  sys¬ 
tem  solution  which  satisfies  different  stakeholders’  expecta¬ 
tions  and  meets  public  safety  and  acceptability.  Therefore, 
identification  and  analysis  of  the  system  requirements  and 
designing  a  system  according  to  the  identified  requirements 
are  the  two  inter-correlated  and  complementary  processes  of 
system  design.  While  these  standards  precisely  specify  the 
processes  involved  in  the  design  of  a  safety  critical  systems, 
Lundteigen  et  al.  (Lundteigen,  Rausand,  &  Utne,  2009)  agree 
that  they  do  not  provide  methods  and  tools  for  efficient  design 


of  complex  engineered  systems.  This  highlights  the  need  for 
appropriate  methods  and  tools  to  support  the  integration  of 
safety  into  the  design  solution. 

2.1.  SysML  for  Complex  Engineered  Systems 

Traditional  methods  and  tools  used  by  system  engineering 
are  mostly  based  on  a  formalism  that  capture  a  variety  of 
system  features,  i.e.,  requirements  engineering,  behavioral, 
functional,  and  structural  modeling,  etc.  Those  with  particu¬ 
lar  focus  on  requirements  engineering  are  the  Unified  Model¬ 
ing  Language  (UML)  (OMG,  2007)  to  support  various  aspect 
of  system  modeling,  Rational  Doors  (IBM,  2010)  to  express 
the  requirements,  and  Reqtify  (GeenSys,  2008)  to  trace  the 
requirements  through  design  and  implementation.  UML  is 
developed  by  the  Object  Management  Group  (OMG)  in  co¬ 
operation  with  the  International  Council  of  Systems  Engi¬ 
neering  (INCOSE).  UML  is  an  Object-oriented  modeling  lan¬ 
guage  that  allows  hierarchical  organization  of  system  compo¬ 
nent  models,  which  in  turn  results  in  easier  reuse  and  main¬ 
tenance  of  the  system  model.  However,  UML  was  originally 
developed  for  software  engineers  and  its  primary  application 
is  software-oriented;  therefore  it  does  not  meet  all  the  system 
engineer’s  expectations.  For  example,  UML  does  not  provide 
a  notion  to  represent  continuous  flows  exchanged  within  the 
system,  i.e.,  Energy,  Material,  and  Signal  (EMS).  The  analy¬ 
sis  of  EMS  flows  are  crucial  in  system  design  safety  verifica¬ 
tion  for  identifying  the  failure  propagation  path  and  identify¬ 
ing  the  common  failure  modes.  For  this  reason,  the  SysML 
profile  was  developed  borrowing  a  subset  of  the  UML  lan¬ 
guage  to  meet  the  requirements  of  a  general  purposed  lan¬ 
guage  for  system  engineering. 

SysML  is  an  efficient  modeling  language  for  constructing  mod¬ 
els  of  complex,  multidisciplinary,  and  large-scale  systems. 
SysML  enables  the  designers  of  a  complex  system  to  model 
the  system  requirements,  structures,  behaviors,  and  paramet¬ 
ric  values  for  a  more  rigorous  description  of  a  system  under 
consideration.  SysML  focuses  on  the  global  features  of  ar¬ 
chitectural  views,  whereas  other  modeling  languages  such  as 
he  Architecture  Analysis  and  Design  language  (AADL)  ad¬ 
dresses  the  more  detailed  platform- oriented  and  physical  as¬ 
pects  of  such  systems.  Nevertheless,  the  wide  variety  of  no¬ 
tations  provided  by  SysML  lacks  formal  and  detailed  seman¬ 
tics  required  for  requirements  verification.  The  goal  of  this 
paper  is  to  bridge  the  gap  between  semi-formal  approaches, 
e.g.,  SysML  and  formal  verification  methods,  e.g.,  model- 
checkers  to  provide  the  system  designers  an  integrated  method 
to  manage  and  verify  the  safety  properties  of  complex  engi¬ 
neered  systems. 

2.2.  Model  Checking  and  Formal  Verification 

Model  checking  is  one  of  the  approaches  to  formal  verifica¬ 
tion  of  finite  state  hardware  and  software  systems  (Henzinger, 
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Figure  1.  Quad-Redundant  EMA  Scheme. 


Ho,  &  Wong-Toi,  1997;  Henzinger,  Nicollin,  Sifakis,  &  Yovine, 
1994).  In  this  approach,  a  design  will  be  modeled  as  a  state 
transition  system  with  a  finite  number  of  states  and  a  set  of 
transitions.  The  design  model  is  in  essence  a  finite-state  ma¬ 
chine,  and  the  fact  that  it  is  finite  makes  it  possible  to  ex¬ 
ecute  an  exhaustive  state-space  exploration  to  prove  that  the 
design  satisfies  its  requirements.  Since  there  is  an  exponential 
relationship  between  the  number  of  states  in  the  model  and 
number  of  components  that  make  up  the  system,  the  compo¬ 
sitional  reasoning  approach  is  used  to  handle  the  large  state- 
space  problem.  The  compositional  reasoning  technique  de¬ 
composes  the  safety  properties  of  the  system  into  local  prop¬ 
erties  of  its  components.  These  local  properties  are  subse¬ 
quently  verified  for  each  component.  However,  Barragan  et 
al.  (Barragan,  Roth,  Faure,  et  al.,  2006)  emphasizes  the  dif¬ 
ficulty  of  transforming  the  global  system  requirements  into 
multi-level  sub-system  and  component’s  local  safety  proper¬ 
ties  that  need  to  be  verified  by  a  model  checker  for  the  design 
of  large  scale  complex  engineered  systems.  More  specifi¬ 
cally,  the  decomposition  of  complex  engineered  systems  into 
multi-domain  sub-systems  involving  electrical,  mechanical, 
and  software  components  makes  the  refinement  and  traceabil¬ 
ity  of  the  global  safety  properties  very  difficult.  Therefore,  a 
systematic  approach  is  required  to  acquire  abstract  require¬ 
ments  along  with  safety  properties,  and  map  them  to  sys¬ 
tem  components  (Evrot,  Petin,  &  Mery,  2006).  Following 
the  work  of  many  researchers,  it  is  concluded  that  the  early 
stages  of  system  design  are  the  most  critical  in  ensuring  that 
the  designed  system  satisfies  its  safety  requirements  (Turner, 
Stone,  &  Bell,  2003;  Stone,  Turner,  &  Stock,  2005;  Kurtoglu 
&  Turner,  2008;  Turner  &  Smidts,  2011),  this  paper  aims  at 
addressing  this  challenge  using  the  system-oriented  SysML- 
based  modeling  approach  combined  with  formal  verification 


technique. 

2.3.  Case  Study 

As  depicted  in  Fig.  1,  a  quad-redundant  Electro-Mechanical 
Actuator  (EMA)  (Balaban  et  al.,  2009)  for  the  Flight  Con¬ 
trol  Surfaces  (FCS)  of  an  aircraft,  developed  in  a  program 
sponsored  by  NASA,  is  used  to  illustrate  and  validate  the  pro¬ 
posed  approach.  The  positions  of  the  surfaces,  A,  C,  and  D, 
in  Fig.  2,  are  usually  controlled  using  a  quad-redundant  actu¬ 
ation  system.  The  FCS  actuation  system  responds  to  position 
commands  sent  from  the  flight  crew,  B  in  Fig.  2,  to  move  the 
aircraft  FCS  to  the  command  positions. 


Figure  2.  Basic  Aircraft  Control  Surfaces. 


The  EM  As  are  arranged  in  a  parallel  fashion;  therefore,  each 
actuator  is  required  to  tolerate  a  fraction  of  the  overall  load. 
To  meet  safety  requirements,  each  actuator  is  required  to  take 
on  the  full  expected  load  from  the  FCS  in  the  extreme  case 
where  all  three  of  the  four  actuators  become  non-operational. 
In  addition,  the  design  should  also  consider  other  issues  such 
as  the  possibility  of  the  actuators  becoming  jammed.  If  one 
actuator  becomes  jammed  in  this  parallel  arrangement,  it  will 
prevent  the  other  ones  from  moving.  Therefore,  a  mechanism 
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Figure  4.  Requirements  Mapping. 


to  disengage  faulty  actuators  from  the  rest  of  the  system  is 
required  to  avoid  the  faulty  actuators  from  becoming  dead¬ 
weights.  Once  an  EM  A  is  disengaged  from  the  system  it  can¬ 
not  be  re-engaged  automatically.  It  is  envisioned  that  this  will 
happen  on  the  ground,  once  the  aircraft  has  landed. 

In  order  for  the  design  to  be  reliable,  additional  redundancies 
in  other  components  of  the  system,  such  as  load  and  position 
sensors  are  required.  Thus,  a  fully  quad-redundant  scheme  is 
envisioned,  as  depicted  in  Fig.  1.  As  illustrated,  the  design 
features  redundancy  in  the  EMAs  and  the  sensor  feedback 
signals.  The  position  command  is  fed  to  the  control  loop, 
while  the  load  from  the  FCS  is  shared  by  the  EMAs.  The 
individual  load,  current,  and  position  response  signals  from 
each  EMA  are  used  to  perform  separate  diagnostics  on  each 
EMA.  Therefore,  faults  are  isolated  to  the  individual  actua¬ 
tors,  which  facilitates  adaptive  on-the-fly  decisions  on  discon¬ 
necting  degraded  EMAs  from  the  load.  A  dedicated  diagnos¬ 
tics  block  performs  actuator  health  assessments,  and  makes 
decisions  on  whether  or  not  to  disengage  any  faulty  actuators 
from  the  flight  control  surface.  The  disengagement  is  made 
possible  by  mechanical  linkages,  which  can  be  disconnected 
from  the  output  shaft  coupling. 


3.  Methodology 

Design  requirements  are  the  specification  of  safety  constraints 
initially  defined  in  the  design.  Requirements  are  modeled  at 
different  levels  of  abstractions.  For  example,  a  higher  level  of 
abstraction  is  used  when  expressing  the  global  system  prop¬ 
erties  and  a  low  level  of  abstraction  is  used  when  expressing 
the  required  features  for  each  system  component,  i.e.  the  bar¬ 
riers  and  materials  to  be  used.  Managing  this  set  of  specifica¬ 
tions  is  based  on  iterative  decomposition  and  substitution  of 
the  abstract  requirements  by  the  requirements  that  are  more 
concrete. 

3.1.  Safety  Requirements  Modeling  Using  SysML 

A  SysML  requirement  diagram  enables  the  transformation  of 
text-based  requirements  into  the  graphical  modeling  of  the  re¬ 
quirements  which  can  be  related  to  other  modeling  elements. 
Fig.  3  depicts  the  decomposition  of  a  single  abstract  require¬ 
ment  into  several  more  explicit  ones.  A  study  by  Blaise  et 
al.  (Blaise,  Lhoste,  &  Ciccotelli,  2003)  confirms  the  effective¬ 
ness  of  such  diagrams  to  facilitate  the  structuring  and  man¬ 
agement  of  requirements  that  are  traditionally  expressed  in 
natural  languages. 

The  next  step  in  the  requirement  analysis  phase  consists  of 
mapping  the  requirements  to  the  corresponding  system  com¬ 
ponents  or  functions.  System  components  are  modeled  as 
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part  of  the  structural  design  of  a  system.  The  structural  de¬ 
sign  model  corresponds  to  the  system  hierarchy  in  terms  of 
systems  and  subsystems,  which  are  modeled  using  the  Block 
Definition  diagram  (BDD).  SysML  blocks  are  the  best  mod¬ 
eling  elements  to  model  multi-disciplinary  systems  and  are 
especially  effective  during  system  specification  and  design. 
They  are  effective  because  blocks  are  not  only  able  to  model 
logical  or  physical  decomposition  of  a  system,  they  also  en¬ 
able  designers  to  define  specification  of  software,  hardware, 
or  human  elements. 

Fig.  4  illustrates  how  a  single  requirement  can  be  satisfied 
by  a  set  of  sub- systems  and  components.  The  requirement 
diagram  is  connected  to  the  structure  diagram  by  a  cross  con¬ 
necting  element  known  as  satisfy.  A  requirement  can  be  sat¬ 
isfied  by  a  component  or  subsystem.  Furthermore,  the  de¬ 
tailed  modeling  of  sub- systems  and  components  are  possible 
through  the  use  of  Internal  Block  Diagram  (IBD).  In  addi¬ 
tion,  blocks  are  a  reusable  form  of  description  that  can  be  ap¬ 
plied  throughout  the  construction  of  system  modeling  if  nec¬ 
essary.  Another  advantage  of  using  blocks  during  the  design 
process  is  their  ability  to  include  both  structural  and  behav¬ 
ioral  features,  such  as  properties  and  operations  that  represent 
the  state  of  the  system  and  behavior  that  the  system  may  dis- 
play. 

Including  properties  as  part  of  the  requirement  modeling  is 
specifically  important  when  verifying  safety  requirements.  As 
Madni.  (Madni,  2007)  demonstrated,  safety  is  a  changing  char¬ 
acteristic  of  complex  systems  that,  once  integrated  into  the 
design,  is  not  preserved  unless  enforced  throughout  system 
operation.  Hollnagel  et  al.  (Hollnagel  et  al.,  2007)  also  con¬ 
firms  that  safety  is  a  feature  that  results  from  what  a  system 
does,  rather  than  a  characteristic  that  the  system  has.  There¬ 
fore,  the  proof  of  safety  is  provided  by  the  absence  of  fail¬ 
ures  and  accidents.  For  this  reason,  ’’safety-proofing”  a  sys¬ 
tem  design  is  never  absolute  or  complete.  Consequently,  the 
proposed  approach  does  not  guarantee  safe  system  operation, 
instead  provides  formal  proof  that  certain  very  specific  be¬ 
havioral  parameters  will  be  achieved.  It  is  for  this  reason  that 
in  this  paper  safety  is  viewed  as  a  system  property. 

A  complete  proof  of  safety  is  possible  through  a  formal  def¬ 
inition  of  different  properties  that  are  linked  to  each  high- 
level  abstract  and  low-level  detailed  requirements.  Fig.  5  rep¬ 
resents  how  a  requirement,  property,  block,  and  behavioral 
model  are  connected  to  one  another.  For  example,  allocate 
as  a  cross  connecting  principle  in  SysML  is  used  to  connect  a 
behavior  to  a  component  in  a  structure  diagram. 

In  the  proposed  approach,  individual  components’  behavior 
in  the  system  are  modeled  as  Labeled  Transition  Systems 
(LTSs),  LTSs  basically  represent  a  finite  state  system.  The 
properties  of  the  LTSs  make  it  ideal  for  expressing  the  be¬ 
havioral  model  of  system  components.  The  LTS  model  is  ex¬ 
pressed  graphically,  or  by  its  alphabet,  transition  relation,  and 
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states  including  single  initial  state.  The  LTS  of  the  system  is 
constructed  from  the  LTS  of  its  subsystems,  and  is  verified 
against  safety  properties  of  the  design  requirements  (Fig.  5). 

3.2.  Safety  Requirements  Verification 

A  model-based  verification  approach  is  proposed  based  on  the 
behavioral  models  of  design  components,  where  behavioral 
specifications  are  associated  with  each  component.  These 
specifications  are  then  used  to  analyze  the  overall  design  ar¬ 
chitecture.  In  this  approach,  a  design  will  be  modeled  as  a 
state  transition  system  with  a  finite  number  of  states  and  a 
set  of  transitions.  The  design  model  is  in  essence  a  finite- 
state  machine,  and  the  fact  that  it  is  finite  makes  it  possible 
to  execute  an  exhaustive  state- space  exploration  to  prove  that 
the  design  satisfies  its  requirements.  Since  there  is  an  ex¬ 
ponential  relationship  between  the  number  of  states  in  the 
model  and  number  of  components  that  make  up  the  system, 
the  compositional  reasoning  approach  is  used  to  handle  the 
large  state-space  problem.  The  compositional  reasoning  tech¬ 
nique  decomposes  the  safety  properties  of  the  system  into  lo¬ 
cal  properties  of  its  components.  These  local  properties  are 
subsequently  verified  for  each  component.  The  combination 
of  these  simpler  and  more  specific  verifications  guarantees 
the  satisfaction  of  the  global  safety  of  the  overall  system  ar¬ 
chitecture  design.  It  is  important  to  note  that,  the  safety  re¬ 
quirements  of  the  components  are  satisfied  only  when  explicit 
assumptions  are  made  on  their  environment.  Therefore  an 
assume -guarantee  (Cobleigh,  Giannakopoulou,  &  Pasareanu, 
2003;  Giannakopoulou,  Pasareanu,  &  Barringer,  2005;  Nam 
&  Alur,  2006;  Chaki,  Clarke,  Sinha,  &  Thati,  2005)  approach 
is  utilized  to  model  each  component  with  regards  to  its  in¬ 
teraction  with  its  environment,  i.e,  the  rest  of  the  system  and 
outside  world. 

Since,  the  LTSs  are  based  on  graphical  modeling,  they  can 
easily  become  unmanageable  for  large  complex  systems.  There¬ 
fore,  an  algebraic  notation  known  as  Finite  State  Process  (FSP) 
(Rodrigues,  2000)  is  used  to  define  the  behavior  of  processes 
in  a  design.  FSP  is  a  specification  language  as  opposed  to  a 
modeling  language,  with  semantics  defined  in  terms  of  LTSs. 
Every  FSP  model  has  a  corresponding  LTS  description  and 
vice  versa.  An  example  FSP  and  LTS  model  of  the  Elec¬ 
tro  Mechanical  Actuator  (EMA)  unit  of  the  quad-redundant 
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EMA  of  Fig.  1  is  provided  in  Table  1  and  Fig.  6  respectively.  M2  will  not  generate  any  EMI  and  RFI  while  operating.  If 

both  rules  hold  then  it  is  concluded  that  the  composition  of 
Table  1.  FSP  Description  of  EMA  both  components  also  satisfies  property  P  ((true)  M\  ||  M2  ( P )). 


1 :  EMA  =  (recLoad  -A  ApplyLoad  -A  (allLoadsCompleted  -A  EMA 
2 :  |  jam  -A  block  — >•  Jammed)), 

3 :  Jammed  =  (recLoad  -A  Jammed 
4 :  |  disengage  — >-  unblock  -A  Disengaged), 

5:  Disengaged  =  (recLoad,  allLoadsCompleted,  timeout  -A  Disen¬ 
gaged). 


applyLoad  jam  block  disengage  unblock 


Figure  6.  LTS  Model  of  the  EMA  Subsystem. 


In  the  defined  model,  a  EMA  receives  the  load  command 
from  the  controller  and  carries  out  the  operation.  The  Elec¬ 
tro  Mechanical  Actuator  is  modeled  in  Table  6  with  Jammed 
and  Disengaged  as  part  of  its  definition.  If  during  the  time 
of  maintaining  the  specified  torque  or  load  the  EMA  func¬ 
tions  according  to  specification,  the  signal  ’’all  loads  are  com¬ 
pleted ”  is  sent  to  the  controller.  Otherwise,  the  EMA  is  con¬ 
sidered  non- operational  or  jammed.  In  the  jammmed  mode, 
the  EMA  is  incapable  of  maintaining  the  required  load  and 
prevents  the  rest  of  the  EM  As  from  moving.  Therefore,  it 
needs  to  be  disengaged  from  the  system. 

After  system  modeling,  the  actual  analysis  of  the  models  is 
carried  out  utilizing  the  Assume  Guarantee  Reasoning  (AGR) 
verification  technique.  In  the  assume-guarantee  methodol¬ 
ogy,  a  formula  contains  a  triple  (A)  M  ( P ) ,  where  M  is  de¬ 
fined  as  a  component,  P  is  a  safety  property,  and  A  is  an 
assumption  or  constraint  on  M’s  environment.  The  formula 
is  proven  correct  if  whenever  M  is  a  component  within  a  sys¬ 
tem  satisfying  A,  then  the  system  also  guarantees  P. 

The  simplest  assume  guarantee  rule  for  checking  a  safety 
property  P  on  a  system  with  two  components  Mi  and  M2 
can  be  defined  as  following  (Henzinger,  Qadeer,  &  Rajamani, 
1998;  Chakietal.,  2005): 

Rule  ASym 


1:  (A)  Mi  (P) 

2  :  (true)  M2  (A) 

(true)  Mi  ||  M2  (P) 

The  first  rule  is  checked  to  ensure  that  the  generated  assump¬ 
tion  restricts  the  environment  of  component  Mi  to  satisfy 
P.  For  example,  the  assumption  A  is  that  there  is  no  Elec¬ 
tromagnetic  Interference  (EMI)  or  Radio  Frequency  Interfer¬ 
ence  (RFI)  in  the  environment  where  component  Mi  oper¬ 
ates;  hence,  P  is  satisfied.  The  second  rule  ensures  that  com¬ 
ponent  M2  respects  the  generated  assumption.  For  example, 
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Figure  7.  An  Overview  of  the  Algorithm  that  Generates  As¬ 
sumptions. 


In  this  research,  the  algorithm  in  (Giannakopoulou,  Pasare- 
anu,  &  Cobleigh,  2004)  is  used  to  automatically  generate 
assume-guarantee  reasoning  at  the  component,  subsystem,  and 
system  level.  The  objective  is  to  automatically  generate  as¬ 
sumptions  for  components  and  their  compositions,  so  that  the 
assume-guarantee  rule  is  derived  in  an  incremental  manner. 
The  framework  of  Figure  7  depicts  the  steps  involved  in  per¬ 
forming  automated  assume-guarantee  reasoning  while  gener¬ 
ating  the  assumptions.  If  rule  (1)  is  violated,  it  means  that  the 
assumption  is  too  weak,  so  it  does  not  prevent  Mi  from  reach¬ 
ing  its  failure  state.  Based  on  the  generated  failure  propaga¬ 
tion  path,  the  algorithm  learns  a  new  assumption  with  more 
restriction  on  the  environment  which  makes  the  assumption 
stronger  than  the  previous  one.  The  iteration  continues  until 
the  first  rule  of  (A)  Mi  (P)  is  addressed.  The  next  step  is  to 
check  the  second  rule  (true)  M2  (A).  If  the  rule  still  holds, 
then  it  is  concluded  that  (true)  Mi  ||  M2  (P).  If  the  check 
fails,  the  algorithm  performs  analysis  on  the  returned  failure 
propagate  path  to  determine  the  reason  for  the  failure.  If  the 
analysis  reveals  that  A  is  not  the  weakest  assumption,  i.e., 
elimination  of  both  EMI  and  RFI  is  not  necessary  and  only 
the  elimination  of  EMI  suffices  to  satisfy  P,  then  the  learning 
algorithm  will  generate  a  new  assumption.  If  the  rules  are  not 
satisfied  with  the  generated  assumptions,  it  is  concluded  that 
(true)  Mi  ||  M2  (P)  violates  the  property  P. 

4.  Application  On  The  Case  Study 

In  the  case  study  of  Fig.  2,  the  Flight  Control  Surface  (FCS) 
must  meet  rigorous  safety  and  availability  requirements  be- 
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Table  2.  Requirement  Mapping. 


Requirement 

Component(s) 

Safety  Requirement  1 

quad-redundant  EMAs 

Safety  Requirement  1.2 

quad-redundant  EMAs 

Safety  Requirement  1.2.1 

Diagnostics 

Safety  Requirement  1.2.2 

EMAs 

Safety  Requirement  1.2.3 

Controller,  Position  Sensor,  and  Shaft 

fore  it  can  be  certified.  The  FCS  has  two  types  of  dependabil¬ 
ity  requirements: 

•  Integrity:  the  FCSs  must  address  safety  issues  such  as 
loss-of  control  resulting  from  aircraft  system  failures,  or 
environment  disturbances. 

•  Availability :  the  system  must  have  a  high  level  of  avail¬ 
ability. 

Therefore,  it  is  critical  for  the  FCS  to  continue  operation  with¬ 
out  degradation  following  a  single  failure,  and  to  fail  safe 
or  fail  operative  in  the  event  of  a  related  subsequent  failure. 
The  movement  of  the  FCS  is  controlled  by  a  quad-redundant 
EM  As.  A  block  diagram  of  the  quad-redundant  EM  As  is  de¬ 
picted  in  Fig.  8.  As  seen  from  the  figure,  the  model  consists 
of  an  EMA  block  which  is  an  hierarchical  representation  of 
four  independent  EM  As.  Each  EMA  is  modeled  via  the  In¬ 
ternal  Block  Definition  diagram  (IBD).  The  individual  EMA 
legs  receive  the  common  position  command,  but  act  indepen¬ 
dently  of  each  other  and  share  the  flight  control  surface  load 
among  themselves. 

Fig.  9  depicts  a  set  of  high-level  requirements.  To  facilitate 
the  verification  process,  each  level  of  requirements  are  asso¬ 
ciated  with  a  formal  FSP  using  property  stereotype  in  SysML. 
Therefore,  satisfying  a  property  PI  is  the  same  as  satisfying 
properties  Pl.l,  P1.2,  and  P1.3. 

The  next  phase  consists  of  identifying  the  design  architecture 
(Fig.  8),  including  sub-systems  and  components  to  map  each 
requirement  to  a  traceable  source.  As  depicted  in  Fig.  4,  re¬ 
quirements  mapping  are  made  possible  by  using  the  satisfy 
relationship  to  link  a  single  or  set  of  blocks  to  one  or  more 
requirements.  The  requirements  mapping  of  quad-redundant 
EM  As  is  presented  in  Table.  2. 

In  order  to  transform  the  requirements  and  the  design  archi¬ 
tecture  presented  in  Fig.  8  into  a  finite  model,  we  use  FSR  As 
an  example,  consider  the  following  FSP  model  of  a  controller 
subsystem  of  the  quad-redundant  EM  As:  The  controller  gets 
the  load  command  from  the  command  unit  and  actively  reg¬ 
ulates  the  current  to  each  EMA  at  every  time  step.  The  dif¬ 
ference  between  the  external  load  and  the  total  actuator  load 
response  is  used  to  accelerate  or  decelerate  the  output  shaft.  If 
the  controller  perceives  that  the  output  shaft  position  response 
is  falling  behind  the  commanded  position,  it  will  increase  the 
current  flow  to  the  EM  As.  As  depicted  in  Table  3,  in  the  FSP 


description  of  the  controller,  a  repetitive  behavior  is  defined 
using  a  recursion.  In  this  context,  recursion  is  recognized  as  a 
behavior  of  a  process  that  is  defined  in  terms  of  itself,  in  order 
to  express  repetition. 

Table  3.  FSP  Description  of  Controller 

1 :  Controller  =  (getLoad[l:L]  — »  Controller!!]), 

2 :  Controller[t:L]  =  (timeout  -A  Controller 

3 :  |  sendLoad— ^allLoadsCompleted— ^getShaftPosition[x:Positions] 

4:  -Aif  (x  >  t)  then  (missionComplete— ^Controller) 

5 :  else  Controller^]). 

The  partial  LTS  model  of  the  controller  is  depicted  in  Fig.  10. 
The  controller  performs  action  <getLoad[l.A\> ,  and  then 
behaves  as  described  by  <C ontr oiler [/]> .  Controller[l\  is 
a  process  whose  behavior  offers  a  choice,  expressed  by  the 
choice  operator  ”|”.  Controller[l]  initially  engages  in  either 
<timeout>  or  <SendLoad>.  The  action  <timeout>  is 
performed  when  all  actuators  fail,  otherwise  <SendLoad> 
is  utilized.  Subsequently,  after  sending  the  required  load  to 
each  EMA,  feedback  signals  are  sent  to  inform  the  controller 
of  completion  of  tasks  by  labeling  the  action  with  <all  Loads 
Completed>.  This  results  in  the  controller  to  perform  the  ac¬ 
tion  <get  Shaft  Position>.  At  this  stage,  the  controller  com¬ 
pares  the  new  position  with  the  required  shaft  position,  if  the 
shaft  has  reached  the  required  position  then  the  <mission  is 
completed>.  Otherwise,  the  behavior  is  repeated  until  the 
shaft  reaches  the  required  position. 


Figure  10.  LTS  Model  of  the  Controller  Subsystem. 


After  modeling  the  behavior  of  each  component  and  sub- system, 
the  design  is  described  by  a  composition  expression.  In  the 
context  of  system  design  engineering,  the  term  composition 
is  similar  to  the  coupled  model.  The  coupled  model  defines 
how  to  couple  several  component  models  together  to  form  a 
new  model,  similarly,  composition  groups  together  individual 
state  machines.  Such  an  expression  is  called  a  parallel  com¬ 
position,  denoted  by  ”||”.  The  ”||”  is  a  binary  operator  that 
accepts  two  LTSs  as  an  input  argument.  In  the  joint  behavior 
of  the  two  LTSs,  the  transition  can  be  performed  by  any  of 
the  LTS  if  the  action  that  labels  the  transition  is  not  shared 
with  the  other  LTS.  Shared  actions  have  to  be  performed  con¬ 
currently.  Table  4  depicts  the  FSP  of  the  joint  behavior  of 
EMA  and  controller.  The  composed  LTS  model  of  the  two 
subsystems  consists  of  161  states  and  62  transitions.  The 
shared  action  between  the  two  models  is  the  <sendLoad> 
action  from  the  controller  and  the  <recLoad>  action  from 
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Figure  8.  Structural  Model  of  the  Quad-redundant  EMAs. 
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Figure  9.  Quad-redundant  EMAs  High-Level  Requirements. 


the  EMA,  therefore,  these  two  are  required  to  be  performed 
synchronously.  In  order  to  change  action  labels  of  an  LTS,  the 
relabeling  operator  ”/”  is  used,  e.g.,  {  recLoad  /  sendLoad  }. 


Table  5  presents  some  of  the  state  transitions  (or  sequence 
of  actions)  produced  by  the  composed  model.  Two  possible 
executions  under  the  EMA’s  nominal  and  faulty  conditions 
are  considered.  In  nominal  mode,  the  EMA  receives  a  re¬ 
quest  from  a  controller  to  provide  two  unit  loads.  At  each 
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Table  4.  Parallel  Composition  of  EMA  (Table  1)  and  Con¬ 
troller  (Table  3) 

1 :  ||  Leg  =  (  EMA  ||  Controller  )  /  {  recLoad  /  sendLoad  }. 

time  step,  EMA  performs  one  unit  load  and  repeats  until  the 
output  shaft  reaches  the  required  position  that  is  when  the 
<missionC omplete>  actions  is  performed.  In  the  failed 
mode,  initial  actions  are  the  same  as  in  nominal  mode  until  an 
EMA  jams.  The  jammed  EMA  blocks  the  rest  of  the  system 
from  moving  until  it  is  disengaged.  The  process  is  followed 
by  the  <U nblock>  action  which  unblocks  the  shaft  allowing 
the  rest  of  the  system  to  be  freed.  By  this  time,  the  EMA  has 
provided  one  unit  load  before  being  disconnected  from  the 
rest  of  the  system.  Since,  the  <ShaftPositionI S>  shows 
the  current  position  of  the  shaft  being  one  instead  of  two,  the 
EMA  is  required  to  perform  one  more  unit  of  load.  However, 
the  disengaged  EMA  is  incapable  of  doing  so  resulting  in  a 
<timeout>.  The  <timeout>  occurs  only  when  there  are  no 
EMAs  to  perform  the  required  load. 

Table  5.  Leg  Subsystem:  Two  Possible  Transitions 


•  const  N  =4  \\  number  of  faulty  EMAs  1 

•  const  M  =4  \\  number  of  EMAs 

•  range  EMAs  =  1..M  \\  EMA  identities 

In  order  to  prevent  the  system  from  reaching  the  catastrophic 
event  of  <timeout> ,  it  is  essential  to  complete  the  mission 
and  provide  the  required  loads  based  on  the  command  signal. 

The  property  of  Table  6,  maintains  a  count  of  faulty  EMAs 
with  the  variable  /.  To  model  the  fact  that  every  command 
signal  must  be  followed  by  a  <missioncomplete> ,  property 
PI,  the  processes  in  lines  3  and  8  are  required  to  constrain 
the  number  of  faulty  EMAs  (/')  to  a  number  defined  by  the 
parameter  of  the  property  ( e.g .  N=4). 

Table  6.  FSP  Model  of  Safety  Property 
1 :  property 

2 :  Fault_Tolerance(N=4)  =  Jammed[0], 

3 :  Jammed[f :  0..M]  =(when(f  <  N)commandLoad[L]  -A  CompleteMission[f] 
when  (f>N)  commandLoad[L]  — »  Jammed [f] 
d[EMAs].jam  — »  Jammed[f+1] 
missionComplete  — »  Jammed[f]), 

CompleteMission[f:O..M]  =  (missionComplete  -a  Jammed[f] 

|  when  (f<N  )  d[EMAs].jam  -A  CompleteMission[f+l] 

|  when  (f=  =N)  d[EMAs].jam  -A  Jammed[f+1]). 


EMA:  Nominal  Mode 

EMA:  Failure  Mode 

1 :  ctrl_getLoad.2 

1 

ctrl_getLoad.2 

2:  EMA_recLoad 

2 

EMA_recLoad 

3 :  EMA_performLoad 

3 

EMA_performLoad 

4:  LoadsCompleted 

3 

EMA  jam 

5:  ShaftPositionls.l 

4 

Shaft-block 

6:  EMA_recLoad 

5 

EMA  .Disengage 

7 :  EMA_performLoad 

6 

Shaft_Unblock 

8:  LoadsCompleted 

7 

LoadsCompleted 

9:  getShaftPosition.2 

8 

ShaftPositionls.l 

10:  EMA_performLoad 

9 

timeout 

11 :  missionComplete 

- 

So  far,  we  provided  the  basis  for  decomposing  and  modeling 
the  system  based  on  the  modular  description  of  the  design 
components  and  subsystems.  In  the  next  phase,  the  process 
of  expressing  the  desired  safety  properties  in  terms  of  a  state 
machine  or  LTS  is  described.  The  advantage  is  that  both  the 
design  and  its  requirements  are  modeled  in  a  syntactically 
uniform  fashion.  Therefore,  the  design  can  be  compared  to 
the  requirements  to  determine  whether  its  behavior  conforms 
to  that  of  the  specifications.  In  the  context  of  this  work,  the 
properties  of  a  system  are  modeled  as  safety  a  FPS.  A  safety 
FPS  contains  no  failure  states.  In  modeling  and  reasoning 
about  complex  systems,  it  is  more  efficient  to  define  safety 
properties  by  directly  declaring  the  desired  behavior  of  a  sys¬ 
tem  instead  of  stating  the  characteristics  of  a  faulty  behavior. 
In  a  FSP,  the  definition  of  properties  is  distinguished  from 
those  of  subsystem  and  component  behaviors  with  the  key¬ 
word  property. 

Based  on  the  requirement  decomposition  model  of  Fig.  9,  the 
composition  model  of  the  properties  Pl.l,  Pl. 2,  and  PI 3  is 
presented  by  the  following  generic  (or  parameterized)  safety 
property  with  the  following  constants  and  a  range  definitions 
is  used: 


If  the  above  property  is  predefined  with  N  =  2,  permitting 
only  two  out  of  four  EMAs  to  fail  during  the  system  opera¬ 
tion,  the  verification  algorithm  of  Fig.  7  verifies  that  the  safety 
property  is  satisfied. 

However,  when  the  property  is  instantiated  allowing  four  EMAs 
to  fail,  the  safety  analysis  verifies  that  the  property  is  violated 
and  a  failure  propagation  path  is  produced.  Therefore,  the 
generic  safety  property  modeled  in  Table  6  verifies  that  the 
system  never  reaches  the  failure  condition  of  total  loss  if  and 
only  if  N  <  M-l  where  N  is  the  number  of  faulty  EMAs  and 
M  is  the  total  number  of  EMAs. 

From  the  result  of  case  study:  the  characterization  of  the  sys¬ 
tem  architecture  by  its  subsystems  and  components  improves 
requirements  specification,  tracking,  and  modeling.  In  addi¬ 
tion,  the  FSP  annotation  of  the  failure  behavior  of  each  of 
component,  and  the  system  level  safety  analysis  based  on 
components’  interaction  lead  to  achieving  a  manageable  veri¬ 
fication  procedure.  As  the  compositional  reasoning  approach 
significantly  reduces  the  number  states  to  be  explored,  ex¬ 
haustive  checking  of  the  entire  state  space  is  made  feasible 
without  the  need  for  a  exhaustive  search.  This  is  especially 
important  where  the  exhaustive  simulation  is  too  expensive 
and  non-exhaustive  simulation  can  miss  the  critical  safety  vi¬ 
olation. 

5.  Conclusion 

There  is  a  growing  demand  for  formal  methods  and  tools  that 
facilitate  the  specification  and  verification  of  complex  engi- 

*by  default  is  set  to  4  but  it  can  be  redefined  during  the  instantiation  process. 


184 


Annual  Conference  of  the  Prognostics  and  Health  Management  Society  2014 


neered  systems  design.  Also,  safety  standards  for  the  de¬ 
sign  of  safety-critical  systems  strongly  recommend  the  use  of 
formal  verification  approach  as  part  of  the  certification  pro¬ 
cess.  However,  these  standards  do  not  specify  how  formal 
approaches  can  be  implemented.  Alternatively,  system  engi¬ 
neering  semi-formal  techniques  for  elicitation  and  structuring 
the  requirements  of  complex  engineered  systems  are  essential 
part  of  the  design  for  electing  the  conceptual  design  that  sat¬ 
isfies  the  identified  requirements. 

In  this  paper,  we  have  proposed  a  system  modeling  and  verifi¬ 
cation  approach  that  combines  these  apparently  contradictory 
views.  The  semi-formal  SysML  techniques  based  on  require¬ 
ment  and  block  diagrams  combined  with  formal  verification 
methods  based  on  the  assume-guarantee  reasoning  are  used 
to  prove  that  the  behavior  of  sub- systems  and  components 
satisfies  the  design  requirements.  The  proposed  approach  is 
based  on  the  mapping  between  the  hierarchical  decomposi¬ 
tion  model  of  the  requirements  and  properties  to  be  satisfied, 
functions  and  behaviors  to  be  realized,  and  sub- systems  and 
components  to  be  implemented. 

The  future  work  will  continue  in  verifying  more  sophisti¬ 
cated  system,  while  taking  into  consideration  safety  proper¬ 
ties  that  are  formulated  using  the  temporal  operators,  i.e.,  un¬ 
til,  before,  or  after.  More  complex  temporal  properties  will 
be  tested.  In  the  case  of  temporal  properties,  satisfying  the 
system  property  is  not  always  equivalent  to  satisfying  a  local 
composition  of  sub-properties.  The  modified  verification  al¬ 
gorithm  will  use  linear  temporal  logic  (LTL)  as  a  specification 
formalism. 
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